✓ RNS 1.4.2 released https://pypi.org/project/rns/
🬤 rns.recipes
Markdown export · communicating-with-serial-interface.md
Copy the block below or save it to a .md file.
# Communicating with serial interface
_Help · started by Necom on Sat, Jul 11, 2026 9:05 AM_
---
## Original post
**Necom** · Sat, Jul 11, 2026 9:05 AM
This computer doesn’t have an IP connection so the only way I can connect to a reticulum network is via LoRa, which makes it a bit annoying to do things that require sending larger amounts of data, like updating reticulum, since I would have to change the LoRa settings to prioritise speed rather than range whenever I need to do something like that.
Ever since I got the Heltec V4s my old V3s have been laying and collecting dust. So I figured, they have wi-fi radios, I like to code and since my brother got me that book about C last year I’ve learnt some of the basics of it so why not take this opportunity to learn how to write firmware for ESP32s and repurpose my V3s. I managed to get them to transmit and receive packets over wi-fi, so now I need to make them communicate with reticulum so they can actually be used as an 802.11 interface. I would write an interface driver but I don’t really know how to do that, I think I remember reading that that would require some kind of class, and I’m not entirely certain what a class even is (well in the context of programming at least) so that seems like a daunting task. Then there’s the pipe interface, but that still requires me to figure out how to communicate over serial, and I don’t really feel like doing that right now. Maybe I’ll do it eventually, if I have to.
For now I figured, the serial interface can already communicate over serial, and as far as I know it just uses a specific byte to separate packets from each other, and then somehow avoids that byte appearing in packets and being confused for a packet delimiter (I don’t know how exactly, just that it does it).
So theoretically, all I need to do is store each byte being received over serial in an array, and when the packet delimiter (0x7E) is received I simply transmit the packet that is in the array, and then I clear the array, so it’s ready for more packets. And when I receive a packet over wi-fi I simply send it over serial followed by 0x7E. All I’m really doing is stripping the packet delimiter from the packet and transmitting it, then adding the delimiter back in at the other end, so the other reticulum instance should receive the exact same packet that the first one sent. And from what I can tell that seems to be exactly what is happening. I plug my Heltec into my computer and look at the serial monitor in the Arduino ide and I can see the path requests and announces coming through, followed by 0x7E.
And yet for some reason when I try to get 2 reticulum instances to communicate like this, they both report receiving 0 bytes on the serial interfaces. So does anyone know if there is some flaw in trying to communicate with the serial interface this way or if I just implemented it badly and the packets actually are being changed somehow?
---
## Reply 1
**Necom** · Mon, Jul 20, 2026 7:39 PM
I got a serial monitor program called tio that can output the exact bytes received on the usb port, from the esp32. The following is a path request for this forum:
7e 08 00 6b 9f 66 01 4d 98 53 fa ab 22 0f ba 47 d0 27 61 00 9c e9 28 08 be 49 8e 9e 05 59 0f f2 7c bf df e4 61 61 20 d6 52 bc 56 d5 7f 78 a8 6b 36 40 65 93 7e
As it seems the packet was successfully received over wifi and sent over serial I’m wondering, is this packet somehow invalid or is reticulum not receiving the packets coming in on the port? Could the interface be misconfigured? This is how the interface is currently configured:
[[ESP32 802.11 Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
mode = gateway
Should an interface configured like this ignore that packet or is this some kind of bug or?
---
## Reply 2
**Necom** · Tue, Jul 21, 2026 6:41 PM
Update: It seems to work with the following configuration:
[[Serial Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
speed = 115200
databits = 8
parity = none
stopbits = 1
The packet loss is pretty high though. I measured it with “rnprobe -v -n 512” and it reported a packet loss of 53.71%, with most packets having a round trip return time of 80 - 200ms, and I think I remember seeing a packet with a time of 500ms once or twice. After further testing it seems most of the packets from my MacBook do reach the raspberry pi, but a lot of packets travelling in the opposite direction, from the raspberry pi to the MacBook, are lost. I tried switching the esp32s, so the MacBook was using the esp32 that the raspberry pi had been using, and vice versa, to see if it would affect this partial unidirectionality somewhat. It did not, most packets from the raspberry pi were still lost, and most packets from the MacBook weren’t. I have no idea what could be causing all this packet loss and partial unidirectionality, so not sure I’m going to be able to do anything about it. Hopefully someone else here might have some idea
---
## Reply 3
**Necom** · Sun, Aug 2, 2026 7:09 AM
Finally I found and fixed the bug causing the packet loss, just had to add a couple parenthesis in the code. "rnprobe -v -n 1024" now shows only 2 packets lost, and most packets have a round trip return time of 100 - 200ms, some are a little under 100ms. The speed varies a little, sometimes it's 1 - 10Kbps, but sometimes it's like 10 - 20Kbps. It's certainly faster than I was able to get with LoRa, and now I don't have to change the LoRa setting to prioritise speed whenever I want to update reticulum. I updated it less than an hour ago, completely over wi-fi
---
## Reply 4
**Mark** · Sun, Aug 2, 2026 10:22 AM
That's awesome. Thanks for sharing your learning and experiments, that was intereseting to read. For someone who's pretty much starting out in programming and just got a book about C, I'd say what you've achieved here is a job pretty well done! Props to you man. Keep learning, keep experimenting and keep building stuff :)
---
## Reply 5
**Mark** · Sun, Aug 2, 2026 11:17 AM
And also, keep pushing the limits :) You can achieve very high reliability and good effective speeds using the ESP32 WiFi chipset. Here's a small demo of what the devices are capable of.
Here, the ESP32-S3 chipset is running my custom 802.11 Weave protocol, running the WiFi transceiver in the long-range PHY mode, at a raw on-air rate of 500 Kbps, 20 MHz channel width. This provides cryptographic multi-hop switching and automatic peer discovery over the switched fabric.
Effective throughput is 300+ Kbps for the actual Reticulum traffic with bi-directional communication over several kilometers.
```txt
$ rnstatus
WeaveInterface[Weave Test]
Status : Up
Mode : Gateway
PHY Rate : 500.00 kbps
CPU load : 3 %
Mem usage : 0.41 %
Switch ID : 17:bb:1f:95
Endpoint : ad:ae:40:8e:d7:3e:75:14
Peers : 1 reachable
Traffic : ↑19.82 KB 2.20 Kbps
↓2.34 MB 301.12 Kbps
```
Also very good reliability and low packet loss:
```txt
$ rnprobe rnstransport.probe db2a9002c9fe24af54169df531d52bf2 -n100
Sent probe 1 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 118.849 milliseconds over 5 hops
[ ... ]
Sent probe 99 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 443.529 milliseconds over 5 hops
Sent probe 100 (16 bytes) to <db2a9002c9fe24af54169df531d52bf2>
Valid reply from <db2a9002c9fe24af54169df531d52bf2>
Round-trip time is 440.827 milliseconds over 5 hops
Sent 100, received 100, packet loss 0.0%
```
---
## Reply 6
**Necom** · Sun, Aug 2, 2026 3:59 PM
Thanks! That means a lot coming from you. I have been very excited about Weave and I’ll definitely use it for the speed increase, but since I have no idea when It’ll be out I’ll just have to stick with my own firmware for now. Do you have any idea when it might be out?
---
## Reply 7
**Mark** · Sun, Aug 2, 2026 8:23 PM
> since I have no idea when It’ll be out
Lol, me neither :) It works quite well, but all the user-facing tooling and management systems are non-existent currently, so it's practically impossible to use unless you know how to send the correct config packets manually ;)
And having your own firmware is also a bit more satisfying in a way, isn't it?
---
## Reply 8
**Mark** · Sun, Aug 2, 2026 8:24 PM
And if you keep messing around with it, you can get the same kinds of speeds as well, or even faster :)
---
## Reply 9
**Necom** · Sun, Aug 2, 2026 8:59 PM
> And having your own firmware is also a bit more satisfying in a way, isn't it?
Indeed, it is!
> And if you keep messing around with it, you can get the same kinds of speeds as well, or even faster :)
Sounds exciting, will definitely try!
---
## Reply 10
**Necom** · Sun, Aug 2, 2026 9:00 PM
> And having your own firmware is also a bit more satisfying in a way, isn't it?
Indeed, it is!
> And if you keep messing around with it, you can get the same kinds of speeds as well, or even faster :)
Sounds exciting, will definitely try!
---
## Reply 11
**Necom** · Tue, Aug 4, 2026 10:20 AM
So I did some more speed tests (and optimising which may or may not have actually impacted the performance much at all). Before I had just been testing the speed by refreshing a nomadnet page and seeing what speed the progress bar was showing, the highest it ever went to was like 56Kbps. That's probably not the best way to measure the speed so I tried Speedtest.py from the code examples. On the client side it seems a bit broken (reporting 2.00 MiB sent at around 14 - 16 Mbps, even though the esp32s are still shining their leds constantly indicating the data is still being sent and hasn't finished yet), but on the server side it seems a little more reliable. With a data_cap of 100*1024 I was getting around 80Kbps, at one point it went as high as 98Kbps. After changing it to 1024*1024 it was reporting as high as 416Kbps. That doesn't seem quite right to me, correct me if I'm wrong but afaIk the serial connection is 1 bit per symbol, so at a baud rate of 115200 the interface shouldn't be able to go higher than 115.2Kbps, no matter how fast the wi-fi is
---
## Reply 12
**Necom** · Tue, Aug 4, 2026 10:25 AM
Wait asterisks make text italic on here? Where is that information? Haven't been able to find any sort of guide regarding what kind of formatting the forum uses. Anyways that's supposed to say 100 times 1024, and 1024 times 1024
---
## Reply 13
**bergie** · Tue, Aug 4, 2026 11:06 AM
**Necom** wrote:
> Wait asterisks make text italic on here? Where is that information? Haven't been able to find any sort of guide regarding what kind of formatting the forum uses.
On the web version the commenting form shows the subset of Markdown supported: **bold**, *italic*, `code` etc
---
## Reply 14
**Mark** · Tue, Aug 4, 2026 6:12 PM
If the ESP boards you have are using the USB CDC driver, and not a USB/UART converter, there's a good chance it doesn't actually care about the baudrate set, and may run at a much higher rate, probably 1Mbaud. It would depend on what is configured with `make menuconfig`.
---
## Reply 15
**Necom** · Wed, Aug 5, 2026 5:39 AM
Well as I said I’m using a pair of Heltec V3s, so they’re using a CP2102. I don’t know what menuconfig is, I’ve definitely read the name before but no recollection of what it is. I’m not using make anyways, I’m using the graphical Arduino IDE, so to build I just hit a button in the top left corner and it compiles the .ino. Well I guess maybe it’s using make behind the scenes.
Even if the baud rate in the firmware didn’t matter wouldn’t the baud rate set in the interface configuration matter? Would Reticulum just completely ignore the speed and communicate at a Mbaud? I did try setting it to 9600 and the interface seemed to entirely stop working cause I wasn’t receiving a response to any path or link requests, so I guess I already answered my own question with that one. Point is as far as I can tell it shouldn’t be higher than 115200
---